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General Switch Management Protocol (GSMP) 
Packet Encapsulations for Asynchronous Transfer Mode (ATM), 
Ethernet and Transmission Control Protocol (TCP) 


Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2002). All Rights Reserved. 


Abstract 


This memo specifies the encapsulation of GSMP (General Switch 
Management Protocol) packets in ATM (Asynchronous Transfer Mode), 
Ethernet and TCP (Transmission Control Protocol). 


Specification of Requirements 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [7]. 


1. Introduction 


GSMP messages are defined in [1] and MAY be encapsulated in several 
different protocols for transport. This memo specifies their 
encapsulation in ATM AAL-5, in Ethernet or in TCP. Other 
encapsulations may be defined in future specifications. 
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2. ATM Encapsulation 


GSMP packets are variable length and for an ATM data link layer they 
are encapsulated directly in an AAL-5 CPCS-PDU [3][4] with an 
LLC/SNAP header as illustrated: 


0 1 2 3 
01234567890123456789012345678901 
—t-4-4-4+-4-4-4-4-4-4-4-t-tHtHtatatatata tata titi titi HHH 
LLC (0xAA-AA-03) | 
=-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 
SNAP (0x00-00-00-88-0C) | 
—t+ot-4-4+-4+-4-4-4-4-4-F-t-tHtatatatatatata tata ti titi ta tata tatat 


:— + —+— + 


GSMP Message a 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Pad (0 - 47 bytes) | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


AAL-5 CPCS-PDU Trailer (8 bytes) + 


+— + — + — + — 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


(The convention in the documentation of Internet Protocols [5] is to 
express numbers in decimal. Numbers in hexadecimal format are 
specified by prefacing them with the characters "0x". Numbers in 
binary format are specified by prefacing them with the characters 
"0b". Data is pictured in "big-endian" order. That is, fields are 
described left to right, with the most significant byte on the left 
and the least significant byte on the right. Whenever a diagram 
shows a group of bytes, the order of transmission of those bytes is 
the normal order in which they are read in English. Whenever a byte 
represents a numeric quantity the left most bit in the diagram is the 
high order or most significant bit. That is, the bit labelled 0 is 
the most significant bit. Similarly, whenever a multi-byte field 
represents a numeric quantity the left most bit of the whole field is 
the most significant bit. When a multi-byte quantity is transmitted, 
the most significant byte is transmitted first. This is the same 
coding convention as is used in the ATM layer [2] and AAL-5 [3][4].) 


The LLC/SNAP header contains the bytes: OxAA OxAA 0x03 0x00 0x00 0x00 
0x88 Ox0C. (0x880C is the assigned Ethertype for GSMP.) 


The maximum transmission unit (MTU) of the GSMP Message field is 1492 
bytes. 
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The virtual channel over which a GSMP session is established between 
a controller and the switch it is controlling is called the GSMP 

control channel. The default VPI and VCI of the GSMP control channel 
for LLC/SNAP encapsulated GSMP messages on an ATM data link layer is: 


VPI = 0 
VCI = 15. 


The GSMP control channel MAY be changed using the GSMP MIB. 
3. Ethernet Encapsulation 


GSMP packets MAY be encapsulated on an Ethernet data link as 
illustrated: 


0 1 2 3 

Oe de 23) 4b 6 T 89 Oecd 2S 4 86 T 8090 D3) 4-6: T 8 9:80 <1 
Potato tito toto titi ti titi titi tita tata tata tata ti tatatatatititatat 
| Destination Address | 
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
E Ne ete EE, 
| Source Address 
Foto titi tai toto titi titi tititi tata titi tata ta titatitatatitatititat 
| Ethertype (0x88-0C) | | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| | 


| GSMP Message | 
Fotatototatao toto tato tata tate taitet acted ited tata tata tatetatetitetat 
| Sender Instance | 
Foto tatotata toto tatai toto toto tata totet ota tata tata tatatatetitetat 
| Receiver Instance | 
ot atotaotato toto tatai toto tatotitetaitet ota tata tata tatetatetitetet 
| Pad | 
Fotatotaotato toto tato tate tatotitataotet ote tata tatetatetitetitetet 
| Frame Check Sequence | 
Fot ated ota o toto tatai tate tate toto toteto tata tate tata tatetatetitetet 


Destination Address 
For the SYN message of the adjacency protocol the Destination 
Address is the broadcast address OxFFFFFFFFFFFF. (Alternatively, 
it is also valid to configure the node with the unicast 48-bit 
IEEE MAC address of the destination. In this case the configured 
unicast Destination Address is used in the SYN message.) For all 
other messages the Destination Address is the unicast 48-bit 
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IEEE. MAC address of the destination. This address may be 
discovered from the Source Address field of messages received 
during synchronisation of the adjacency protocol. 


Source Address 
For all messages, the Source Address is the 48-bit IEEE MAC 
address of the sender. 


Ethertype 
The assigned Ethertype for GSMP is 0x880C. 


GSMP Message 
The maximum transmission unit (MTU) of the GSMP Message field is 
1492 bytes. 


Sender Instance 
The Sender Instance number for the link obtained from the 
adjacency protocol. This field is already present in the 
adjacency protocol message. It is appended to all non-adjacency 
GSMP messages in the Ethernet encapsulation to offer additional 
protection against the introduction of corrupt state. 


Receiver Instance 
The Receiver Instance number is what the sender believes is the 
current instance number for the link, allocated by the entity at 
the far end of the link. This field is already present in the 
adjacency protocol message. It is appended to all non-adjacency 
GSMP messages in the Ethernet encapsulation to offer additional 
protection against the introduction of corrupt state. 


Pad 
After adjacency has been established the minimum length of the 
data field of an Ethernet packet is 46 bytes. If necessary, 
padding should be added such that it meets the minimum Ethernet 
frame size. This padding should be bytes of zero and is not to be 
considered part of the GSMP message. 


Frame Check Sequence 
The Frame Check Sequence (FCS) is defined in IEEE 802.3 [6] as 
follows: 


Note: This section is included for informational and historical 
purposes only. The normative reference can be found in IEEE 
802.3 Standard [6]. 


"A cyclic redundancy check (CRC) is used by the transmit and 
receive algorithms to generate a CRC value for the FCS field. 
The frame check sequence (FCS) field contains a 4-byte (32-bit) 
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cyclic redundancy check (CRC) value. This value is computed as 
a function of the contents of the source address, destination 
address, length, LLC data and pad (that is, all fields except 
the preamble, SFD, FCS and extension). The encoding is defined 
by the following generating polynomial. 


G (xX) =xX^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^ 
7T+x°54+x°44+x*°24+x°1." 


The procedure for the CRC calculation can be found in [6]. 


After the adjacency protocol has achieved synchronisation, for every 
GSMP message received with an Ethernet encapsulation, the receiver 
must check the Source Address from the Ethernet MAC header, the 
Sender Instance, and the Receiver Instance. The incoming GSMP 
message must be discarded if the Sender Instance and the Source 
Address do not match the values of the Sender Instance and the Sender 
Name stored by the "Update Peer Verifier" operation of the GSMP 
adjacency protocol. The incoming GSMP message must also be discarded 
if it arrives over any port other than the port over which the 
adjacency protocol has achieved synchronisation. In addition, the 
incoming message must also be discarded if the Receiver Instance 
field does not match the current value for the Sender Instance of the 
GSMP adjacency protocol. 


4. TCP/IP Encapsulation 


When GSMP messages are transported over an IP network, they MUST be 
transported using the TCP encapsulation. TCP provides reliable 
transport, network flow control, and end-system flow control suitable 
for networks that may have high loss and variable or unpredictable 
delay. 


For TCP encapsulations of GSMP messages, the controller runs the 
client code and the switch runs the server code. Upon 
initialisation, the server is listening on GSMP’s TCP port number: 
6068. The controller establishes a TCP connection with each switch 
it manages. The switch under control MUST be a multi-connection 
server (PORT 6068) to allow creation of multiple control sessions 
from N GSMP controller instances. Adjacency protocol messages, which 
are used to synchronise the controller and switch and maintain 
handshakes, are sent by the controller to the switch after the TCP 
connection is established. GSMP messages other than adjacency 
protocol messages MUST NOT be sent until after the adjacency protocol 
has achieved synchronisation. The actual GSMP message flow will 
occur on other ports. 
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4.1 Message Formats 


GSMP messages are sent over a TCP connection. A GSMP message is 
processed only after it is entirely received. A four-byte TLV header 
field is prepended to the GSMP message to provide delineation of GSMP 
messages within the TCP stream. 


0 di 2 3 

0A 345 Oy WB DOr Te 203) A T O 99-01 D2 SA Se 6°28 9 OL 
foto o bata tatatatototo toto tatatatatotito ta tatatatititatetototatat 
| Type (0x88-0C) | Length | 
| -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ +++ 
| 


GSMP Message 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type 
This 2-byte field indicates the type code of the following 
message. The type code for GSMP messages is 0x88-0C (i.e., the 


same as GSMP’s Ethertype). 


Length 
This 2-byte unsigned integer indicates the total length of the 
GSMP message only. It does not include the 4-byte TLV header. 


4.2 TCP/IP Security consideration 


When GSMPv3 is implemented for use in IP networks, provisions for 
security between the controller and client MUST be available and MUST 
be provided by IP Security [IPSEC]. In this case, the IPSEC 
Encapsulation Security Payload (ESP) MUST be used to provide both 
integrity and confidentiality. 


5. Security Considerations 


The security of GSMP’s TCP/IP control channel has been addressed in 
Section 4.2. For all uses of GSMP over an IP network it is REQUIRED 
that GSMP be run over TCP/IP using the security considerations 
discussed in Section 4.2. Security using ATM and Ethernet 
encapsulations MAY be provided at the link layer. Discussion of 
these methods is beyond the scope of this specification. For secure 
operation over any media, the IP encapsulation with IPsec SHOULD be 
used. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2002). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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